1. Field of the Invention
The present invention relates in general to the field of virtual multiprocessors, and in particular to mechanisms that provide for dynamic configuration of resources within a virtual multiprocessor between one or more virtual processing elements.
2. Description of the Related Art
Present day designers employ many techniques to increase microprocessor performance. Most microprocessors operate using a clock signal running at a fixed frequency. Each clock cycle, the circuits of the microprocessor perform their respective functions. According to Hennessy and Patterson, the true measure of a microprocessor's performance is the time required to execute a program or collection of programs. From this perspective, the performance of a microprocessor is a function of its clock frequency, the average number of clock cycles required to execute an instruction (or alternately stated, the average number of instructions executed per clock cycle), and the number of instructions executed in the program or collection of programs. Semiconductor scientists and engineers continue to provide advances in the art that enable microprocessors to run at increasingly faster clock frequencies. These advances predominately enable the reduction of transistor sizes, which results in faster switching times within an integrated circuit designed therefrom. The number of instructions executed is largely fixed by the task to be performed by the program, although it is also affected by the instruction set architecture of the microprocessor. However, large performance increases have been realized by architectural and organizational techniques that improve the instructions per clock cycle, in particular by techniques that allow for parallel execution of instructions (i.e., “parallelism”).
One parallelism technique that has improved the instructions per clock cycle of microprocessors, as well as their clock frequency, is pipelining. Pipelining overlaps execution of multiple instructions within pipeline stages of the microprocessor in a manner substantially similar to stages in an assembly line. In an ideal situation, each clock cycle one instruction moves down the pipeline to a new stage, which performs a different function on the instructions. Thus, although each individual instruction takes multiple clock cycles to complete, because the multiple cycles of the individual instructions overlap, the average clocks per instruction is reduced. The performance improvements of pipelining may be realized to the extent that the instructions in the program permit it, namely to the extent that an instruction does not depend upon its predecessors in order to execute and can therefore execute in parallel with its predecessors, which is commonly referred to as instruction-level parallelism. Another way in which instruction-level parallelism is exploited by contemporary microprocessors is the issuing of multiple instructions for execution during the same clock cycle to different functional units, which each perform their directed functions during that clock cycle. A microprocessor that accomplishes instruction-level parallelism in this manner is commonly referred to as a “superscalar” microprocessor.
The parallelism mechanisms discussed above pertain to parallelism at the individual instruction-level. However, the performance improvement that may be achieved through exploitation of instruction-level parallelism is limited. Various constraints imposed by limited instruction-level parallelism and other performance-constraining issues have recently renewed an interest in exploiting parallelism at the level of blocks, or sequences, or streams, or threads of instructions. This level of parallelism is commonly referred to as thread-level parallelism. A thread is simply a sequence, or stream, of program instructions. A multithreaded microprocessor concurrently executes multiple threads according to some scheduling policy that dictates the fetching and issuing of instructions of the various threads, such as interleaved, blocked, or simultaneous multithreading. A multithreaded microprocessor typically allows the multiple threads to share the functional units of the microprocessor (e.g., instruction fetch and decode units, caches, branch prediction units, and load/store, integer, floating-point, SIMD, etc. execution units) in a concurrent fashion. However, multithreaded microprocessors include multiple sets of hardware/firmware resources, or thread contexts, for storing the unique state of each thread to facilitate the ability to quickly switch between threads to fetch and issue instructions. For example, each thread context includes its own program counter for instruction fetching and thread identification information, and typically also includes its own general purpose register set.
One example of a performance-constraining issue addressed by multithreading microprocessors is the fact that accesses to memory outside the microprocessor that must be performed due to a cache miss typically have a relatively long latency. The memory access time of a contemporary microprocessor-based computer system is commonly between one and two orders of magnitude greater than the cache hit access time. Consequently, while the pipeline is stalled waiting for the data from memory, some or all of the pipeline stages of a single-threaded microprocessor may be idle performing no useful work for many clock cycles. Multithreaded microprocessors may alleviate this problem by issuing instructions from other threads during the memory fetch latency, thereby enabling the pipeline stages to make forward progress performing useful work, somewhat analogously to, but at a finer level of granularity than, an operating system performing a task switch in response to a page fault. Other examples of performance-constraining issues are pipeline stalls and their accompanying idle cycles due to a branch misprediction and concomitant pipeline flush, or due to a data dependence, or due to a long latency instruction such as a divide instruction. Again, the ability of a multithreaded microprocessor to issue instructions from other threads to pipeline stages that would otherwise be idle may significantly reduce the time required to execute the program or collection of programs comprising the threads. Another problem, particularly in embedded systems, is the wasted overhead associated with interrupt servicing. Typically, when an input/output device signals an interrupt event to the microprocessor, the microprocessor switches control to an interrupt service routine, which requires saving of the current program state, servicing the interrupt, and restoring the current program state after the interrupt has been serviced. A multithreaded microprocessor provides the ability for event service code to be its own thread having its own thread context. Consequently, in response to the input/output device signaling an event, the microprocessor can quickly—perhaps in a single clock cycle—switch to the event service thread, thereby avoiding incurring the conventional interrupt service routine overhead.
Just as the degree of instruction-level parallelism dictates the extent to which a microprocessor may take advantage of the benefits of pipelining and superscalar instruction issue, the degree of thread-level parallelism dictates the extent to which a microprocessor may take advantage of multithreaded execution. An important characteristic of a thread is its independence of the other threads being executed on the multithreaded microprocessor. A thread is independent of another thread to the extent its instructions do not depend on instructions in other threads. The independent characteristic of threads enables the microprocessor to execute the instructions of the various threads concurrently. That is, the microprocessor may issue instructions of one thread to execution units without regard to the instructions being issued of other threads. To the extent that the threads access common data, the threads themselves must be programmed to synchronize data accesses with one another to insure proper operation such that the microprocessor instruction issue stage does not need to be concerned with the dependences.
As may be observed from the foregoing, a processor with multiple thread contexts concurrently executing multiple threads may reduce the time required to execute a program or collection of programs comprising the multiple threads. However, the introduction of multiple thread contexts also introduces a new set of problems, particularly for system software, to manage the multiple instruction streams and their associated thread contexts. And the present inventors have noted yet another level that is required for improving the parallelism associated with instruction execution in a microprocessor. In this and related applications, the present inventors address the provision of virtual processing elements within the same microprocessor. Taken to this level, a multithreaded virtual processing element, in addition to implementing multiple program counters and thread contexts to ensure the effective switching of program threads, implements all of the resources necessary to provide for a single instantiation of a given instruction set and privileged resource architecture that is sufficient to execute a per-processor operating system image. Effectively, a microprocessor that implements N virtual processing elements (i.e., a “virtual multiprocessor” having N virtual processing elements) appears to operating system software as an N-way symmetric multiprocessor. The physical difference between a virtual multiprocessor according to the present invention and a conventional symmetric multiprocessor is that, in addition to sharing memory and some level of connectivity, the virtual processing elements within a virtual multiprocessor also share on-chip resources, or attributes, of the virtual multiprocessor such as, for example, instruction fetch and issue logic; address translation logic (e.g., translation lookaside buffer logic); functional units such as integer units, floating point units, multimedia units, media acceleration units, and SIMD units; and coprocessors. In addition, the virtual processing units must share performance attributes, or utilization aspects (e.g., “bandwidth”), of the virtual multiprocessor, which are determined largely based upon the number of threads that are allocated to each of the virtual processing elements, the extent that the threads associated with one virtual processing element can take priority over the threads associated with other virtual processing elements when execution is required, and the allocation of certain processor-wide resources (e.g., load/store buffers) to the virtual processing elements. For example, consider an embedded system in which two distinct kinds of processing are taking place: real-time compression of audio or video data, and operation of a graphical user interface. Using late 20th century technology, these tasks might be accomplished by using two different processors: a real-time digital signal processor to handle the multimedia data and an interactive processor core which runs a multitasking operating system. Yet, the present invention allows for these two functions to be performed on the same virtual multiprocessor. Two virtual processing elements of the virtual multiprocessor would be employed: one dedicated to performing the multimedia processing tasks, and the other dedicated to performing the user interface tasks. Employing two virtual processing elements solves the problem of the co-existence, or co-instantiation of two different software paradigms, but it does not guarantee the real-time performance requirements in the same way as a dedicated processor, because the multimedia virtual processing element and the user interface virtual processing element must share certain resources within the virtual multiprocessor and the performance of applications executing on a virtual multiprocessor are, as alluded to above, based upon how those resources, or attributes are allocated to each of the virtual processing elements therein.
To fabricate a virtual multiprocessor that has resources precisely tailored to a specific multiprocessing application would be excessively cost-ineffective in a market where multiprocessing applications exhibit a very wide and diverse set of resource requirements. Thus, the present inventor has observed that it is very desirable to provide a virtual multiprocessor that can be employed across this wide range of multiprocessing applications. He has additionally noted that it is desirable that the virtual multiprocessor include mechanisms for configuration of resources to various virtual processing elements therein by software. Such mechanisms should allow the virtual multiprocessor to be configured with one or more virtual processing elements, where each of the virtual processing elements is configured to execute one or more threads. Furthermore, it is desired that the resources be dynamically configurable by trusted virtual processing elements at run-time, and moreover that a mechanism be provided to revoke configuration privileges.